Programming of instrumentation can be a tedious and/or complex task. The test engineer, or other instrumentation programmer, must understand all aspects of the signals that need to be generated, captured and analyzed and how to use the instruments available to support and achieve their objectives. Signals are typically described in voltage, frequency and timing parameters or relationships. Prompting the test engineer with visual cues, such as in a GUI, the programming of instrumentation to create capture and analyze signals is intuitive. Reducing the complexities of programming the instrumentation naturally focuses the test engineer on the objectives of signal characteristics and content.
The reduction in programming complexity for the test engineer makes their task easier, consuming less of their time on the byproduct overhead task of programming which is a necessity associated with the use of instrumentation automation. Requirements to provide support documentation, such as flow charts and/or test diagrams, are generated automatically by I2T. This ensures the quality, reliability and accuracy of complex test programming requirements and improves the efficiency of the test engineer.
Even with thorough knowledge of signals, programming instrumentation is still a time-consuming task. To automate instrument programming, the test engineer must have knowledge of not only what to program but they also need to have knowledge on how to send programming information to the instruments. Accomplishing instrument programming is environment-dependent but the majority of today's common system architectures provide documentation for each instruments API or they document the native instrument language.
Two dominant instrument class types exist from a programming perspective; register-based and message-based. Register-based instrument manufacturers document their API in the programmer's/user's guide or provide a register map and description of how to use the various registers to automate control programmatically in their programmer's/user's guide. Message-based instruments document a native instrument language for automating program control using a word serial protocol.
The most common implementation today is the Standard Commands for Programmable Instruments (SCPI) standard, so message-based instrument manufacturers document their API in the programmer's/user's guide and/or document their native SCPI language and how to automate programmatic control of an instrument in their programmer's/user's guide. If one of these instrument classes and/or common practices is not available for the instrument, then the programming task becomes more difficult.
Very often, the programmer's/user's guide set forth the critical setup criteria for and/or mutual and mutually exclusive instrument rules for modes of operation that must be adhered to for proper functionality. If the test engineer is not an experienced programmer, then the task can become exponentially more difficult. As the programming task becomes more of a challenge, adverse risk to the quality, reliability, transportability and accuracy of the code simultaneously compounds.
To successfully accomplish programming, an instrument requires the user to evaluate and know each function within the API or SCPI language and all the parameters related to the particular functions necessary in order to automate instrument control. To save time, reduce adverse risk and increase code quality, reliability, transportability and accuracy, code to automate program control of each instrument is generated automatically as the user clicks through the I2T's graphical user interface. The automatically generated code can be inserted into the desired editor, interpreter compiler or programming paradigms ensuring the instruments automated control is executed exactly the way the test engineer accomplished the programming task using the I2T graphical user interface.
A need often arises for a reliable means for a user, in particular an inexperienced programmer, to accomplish useable programming code themselves. By using the I2T's graphical user interface described in detail below, this need is met.
In the realm of Automatic Testing, a user may require a signal generator and/or a signal analyzer to ascertain the operational quality/integrity or diagnose faulty elements in various electronic devices. In doing this, many tests have to be written which then must be logically executed in the designed sequence to obtain one or more desired test objectives. The I2T can solve both of these problems. The tests can be written using the macro generation as well as the test creation tool. The I2T solves the sequencer problem allowing the user to define which tests are to be run and what order to run them. Additionally, I2T will process and log the test results.